查看原文
其他

你不知道的tcp半连接、全连接全在这里了(1)

Cloud研习社 Cloud研习社 2023-06-06

教程每周二、四、六更新


在 TCP 三次握手的时候,Linux 内核会维护两个队列,分别是:

  • 半连接队列,也称 SYN 队列;
  • 全连接队列,也称 accepet 队列;
服务端收到客户端发起的 SYN 请求后,内核会把该连接存储到半连接队列,并向客户端响应 SYN+ACK,接着客户端会返回 ACK,服务端收到第三次握手的 ACK 后,内核会把连接从半连接队列移除,然后创建新的完全的连接,并将其添加到 accept 队列,等待进程调用 accept 函数时把连接取出来。


半连接和全连接队列都有最大长度限制,当超出最大长度时,系统将无法创建新连接。

在服务端可以使用 ss 命令,来查看 TCP 全连接队列的情况:

# 先看看listen状态的连接
[root@cloudstudy linux-kernel]# ss -lnt
State      Recv-Q Send-Q               Local Address:Port                              Peer Address:Port              
LISTEN     0 128 *:22                                           *:*
LISTEN     0 128 127.0.0.1:631                                          *:*
LISTEN     0 128 127.0.0.1:6010                                         *:*
LISTEN     0 128 :::111                                         :::*
LISTEN     0 128 :::80                                          :::*
LISTEN     0 128 :::22                                          :::*
LISTEN     0 128 ::1:631                                         :::*
LISTEN     0 128 ::1:6010                                        :::*

# 再看看其他状态的连接情况
[root@cloudstudy linux-kernel]# ss -nt
State      Recv-Q Send-Q               Local Address:Port                              Peer Address:Port              
ESTAB      0 36 10.0.0.136:22                                    10.0.0.1:50904


为什么ss 加不加 -l 参数send-Q的指标不一样呢?

这是因为:加了-l参数显示的才是全连接队列的长度。换句话说,当状态是LISTEN时,Recv-Q 和Send-Q 分别代表:

Recv-Q     当前全连接队列的大小,也就是当前已完成三次握手并等待服务端 accept() 的 TCP 连接;

Send-Q     当前全连接最大队列长度,上面的输出结果说明监听 22等端口的 TCP 服务,最大全连接长度为 128。

当状态不是LISTEN时:

  • Recv-Q:已收到但未被应用进程读取的字节数;

  • Send-Q:已发送但未收到确认的字节数;


实战调整全连接队列大小


客户端:centos7.9    10.0.0.11

服务端:centos7.9     10.0.0.62   nginx  端口80

测试工具:wrk

# 从客户端执行
# -t 6 表示启动6个测试线程
# -c 30000 表示3万个连接
# -d 60s 表示持续压测60s
wrk -t 6 -c 30000 -d 60s http://10.0.0.62


在服务端用ss命令查阅TCP全连接队列的情况:

# 服务端查阅tcp全连接队列的情况
[root@rs01 ~]# ss -lnt | grep 80
LISTEN     75    128          *:80                       *:*
LISTEN     0      128       [::]:80                    [::]:*
[root@rs02 ~]# ss -lnt | grep 80
LISTEN     129    128          *:80                       *:*
LISTEN     0      128       [::]:80                    [::]:*


其间共执行了两次 ss 命令,从上面的输出结果,可以发现当前 TCP 全连接队列上升到了 129 大小,超过了最大 TCP 全连接队列。

当超过了 TCP 最大全连接队列,服务端则会丢掉后续进来的 TCP 连接,丢掉的 TCP 连接的个数会被统计起来,我们可以使用 netstat -s 命令来查看:

[root@rs02 ~]# netstat -s | grep overflowed
    241307 times the listen queue of a socket overflowed


上面看到的 241307times ,表示全连接队列溢出的次数,注意这个是累计值。可以隔几秒钟执行下,如果这个数字一直在增加的话肯定全连接队列偶尔满了。

从上面的模拟结果,可以得知,当服务端并发处理大量请求时,如果 TCP 全连接队列过小,就容易溢出。发生 TCP 全连接队溢出的时候,后续的请求就会被丢弃,这样就会出现服务端请求数量上不去的现象。

实际上,丢弃连接只是 Linux 的默认行为,我们还可以选择向客户端发送 RST 复位报文,告诉客户端连接已经建立失败。

[root@rs01 ~]# cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0


tcp_abort_on_overflow 共有两个值分别是 0 和 1,其分别表示:

  • 0 :如果全连接队列满了,那么 server 扔掉 client 发过来的 ack ;

  • 1 :如果全连接队列满了,server 发送一个 reset 包给 client,表示废掉这个握手过程和这个连接;

如果要想知道客户端连接不上服务端,是不是服务端 TCP 全连接队列满的原因,那么可以把 tcp_abort_on_overflow 设置为 1,这时如果在客户端异常中可以看到很多 connection reset by peer 的错误,那么就可以证明是由于服务端 TCP 全连接队列溢出的问题。(建议设置为0)


如何增大TCP全连接队列


当发现 TCP 全连接队列发生溢出的时候,我们就需要增大该队列的大小,以便可以应对客户端大量的请求。

TCP 全连接队列足最大值取决于 somaxconn 和 backlog 之间的最小值,也就是min(somaxconn, backlog)。

  • somaxconn 是 Linux 内核的参数,默认值是 128,可以通过 /proc/sys/net/core/somaxconn 来设置其值;

  • backlog 是 listen(int sockfd, int backlog) 函数中的 backlog 大小,Nginx 默认值是 511,可以通过修改配置文件设置其长度;

前面模拟测试中,我的测试环境:

  • somaxconn 是默认值 128;

  • Nginx 的 backlog 是默认值 511

所以测试环境的 TCP 全连接队列最大值为 min(128, 511),也就是 128.

现在我们重新压测,把 TCP 全连接队列搞大,把 somaxconn 设置成 5000:


[root@rs01 ~]# echo 5000 > /proc/sys/net/core/somaxconn


接着把 Nginx 的 backlog 也同样设置成 5000:

# /etc/nginx/nginx.conf
    server {
        listen 80 default backlog=5000;
        listen [::]:80;
......


# 重启nginx后查看:
[root@rs01 ~]# systemctl restart nginx
[root@rs01 ~]# ss -lnt | grep 80
LISTEN 0      5000         *:80                       *:*                  
LISTEN 0      511       [::]:80                    [::]:*


从执行结果,可以发现 TCP 全连接最大值为 5000。

再次压测:

wrk -t 6 -c 30000 -d 60s http://10.0.0.62


服务端执行 ss 命令,查看 TCP 全连接队列使用情况:

[root@rs01 ~]# ss -lnt | grep 80
LISTEN     204     5000         *:80                       *:*
LISTEN     0      511       [::]:80                    [::]:*


从上面的执行结果,可以发现全连接队列使用增长的很快,但是一直都没有超过最大值,所以就不会溢出:

[root@rs01 ~]# netstat -s | grep overflowed
    181404 times the listen queue of a socket overflowed
# 181404是没调整之前的丢弃情况,现在看只要数据没有变化就说明队列没有继续溢出。


说明 TCP 全连接队列最大值从 128 增大到 5000 后,服务端抗住了 3 万连接并发请求,也没有发生全连接队列溢出的现象了。

总结:如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃,就应该调大 backlog 以及 somaxconn 参数。

下一期我们来看看半连接的问题,周四见喽!

参考连接:https://zhuanlan.zhihu.com/p/144785626



推荐阅读


干货 | PXE+kickstart无人值守批量装机(原理与架构)

干货 | PXE+kickstart无人值守批量装机(实战部署)

ifconfig已淘汰,ip登场

Linux 云计算 学习路线(建议收藏)
放后台的Linux任务没有了,试试这个命令

Linux 网络状态工具 ss 命令详解

这次终于搞明白VLAN技术了

终于有人把敏捷、DevOps、CI、CD讲清楚了


看完本文有收获?请分享给更多人

推荐关注「Cloud研习社」,带你从零开始掌握云计算技术!

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存